Method and Devices for Duplicated Packets Identification During Handover

ABSTRACT

A method and devices for performing a handover of a data unit based communication that involves a sequence of data units from a first connection ( 51 ) between a first sender ( 10 ) and a receiver ( 4 ) to a second connection ( 52 ) between a second sender ( 20 ) and said receiver ( 4 ), which comprises indicating to thc receiver ( 4 ) a reference data unit among data units provided to both the first sender ( 10 ) and the second sender as a part of the handover, and where the receiver, based on the reference data unit, keeps a record for identifying such data units among those data units provided to both the first sender ( 10 ) and the second sender ( 20 ) that were sent over the first connection ( 51 ) and successfully.received by the receiver ( 4 ), prior to the communication having been passcd to the second communication ( 52 ).

FIELD OF THE INVENTION

The present invention relates to a method of performing a handover of adata unit based communication from a first connection between a firstsender and a receiver to a second connection between a second sender andsaid receiver, as well as to senders and receivers capable of performingsuch a handover.

BACKGROUND OF THE INVENTION

The concept of handing over a communication from a first connection to asecond connection is well known. There can be many reasons forperforming such a handover, e.g. because the first connectiondeteriorates in quality due to the movement of the receiver, the senderassociated with the first connection becomes overloaded, the secondconnection has became available and has more desirable properties, e.g.provides a higher data rate, etc.

Performing a handover from a first connection to a second connectionmeans that the communication underway is discontinued over the firstconnection and continued over the second connection. It is possible thatthe second connection must first be established before performing thehandover, and the first connection is itself discontinued after thehandover, but this is not necessarily the case, as a handover can alsobe performed between standing connections whose existence is independentof the handover procedure.

One of the problems involved in handovers is that of data loss. Namely,in the course of transferring a communication from a first connection toa second connection, it is possible that parts of the data beingtransmitted to the sender are lost, e.g. because the data is queued orprocessed at the sender of the first connection, and was not completelytransmitted at the time that the communication is discontinued over thefirst connection. In order to solve this problem, it has been suggestedto perform so-called multicast handovers, in which prior todiscontinuing the communication over the first (or old) connection, thedata destined for the receiver is provided to both the sender of thefirst connection and the sender of the second (or new) connection.

It is noted that a handover scenario can comprise a plurality of secondconnections, i.e. that there can be several candidates to which thecommunication may be handed over. If this is the case, then themulticasting handover provides the data to all of the secondconnections.

As an example, if there are two access routers, each associated with itsown access network, for wireless communication with a mobile receiver,where the connections from the access routers to the mobile are linklayer connections or links, then the performance of a multicast handovercan be implemented by having the first access router (the access of thefirst link from which the communication is being handed over) duplicatethe layer 3 (i.e. above the link layer) data units (e.g. IP packets)that are to be sent to the mobile receiver, and forward these to thesecond access router (the access router of the second connection towhich the communication is being handed over). The second access routerqueues the multicast data units, and starts sending upon receiving anappropriate enablement signal.

PROBLEM UNDERLYING THE INVENTION

The above-described concept of multicast handover leads to a number ofproblems. One of these problems is that although multicasting allows toavoid the loss of data during handover, it can on the other hand lead tosending the same data over several connections, which constitutes awaste of network resources and is therefore very inefficient. Anotherproblem is that the reception of duplicated data at the receiver canlead to severe interference with the functionality of data handling atprotocol layers above the layer governing the connections in questions.This can e.g. be explained by using the example of link layerconnections over which a TCP (Transmission Control Protocol)communication is being handled and for which a handover is performed.From the moment at which multicasting starts, IP packets are duplicatedand also sent to the new access router. By the time at which thehandover occurs, a potentially large number of IP packets is queued atthe new access router, although many may have already been received atthe receiver over the old link. These IP packets are now againtransmitted after the handover. Apart from the waste of resources forthe transmission, these IP packets will be perceived by the TCP receiveras duplicates and will force the TCP receiver to send so-calledduplicate acknowledgements (DUPACKs) back to the TCP sender. For everythree DUPACKs the TCP sender will reduce its transmission rate by 50%,since it assumes that they are caused by a packet loss due to networkcongestion. As a consequence, the performance of the TCP communicationcan be drastically reduced. This is particularly annoying, since it cantake a long time before the TCP congestion control algorithm will againreach a high sending rate.

OBJECT OF THE INVENTION

The object of the present invention is to generally provide an improvedmethod and system for performing a multicast handover.

SUMMARY OF THE INVENTION

This object is solved by the subject-matter of the independent claims ofthe present application. Advantageous embodiments are described in thedependent claims.

In accordance with a method of the present invention, when performing ahandover of a data unit based communication from a first connectionbetween a first sender and a receiver to a second connection between asecond sender and said receiver, in which multicasting is used, i.e.some of the data units destined for the receiver are provided to boththe first sender and the second sender, it is proposed to indicate tothe receiver a reference data unit among the multicast data units, wherethe receiver then keeps a record for identifying such data units amongthe multicast data units that where sent over the first connection (i.e.the initial connection of the handover) and successfully received.

In this way, the receiver can avoid the negative impact caused byreceiving data that was duplicated on account of the handover process.For example, the receiver can simply silently discard those multicastdata units that were already successfully received over the firstconnection.

According to a preferred embodiment, the receiver sends information tothe second sender, such that the second sender is capable of identifyingthose data units among the multicast data units that were alreadysuccessfully received over the first connection. In this way, the secondsender can e.g. refrain from sending these data units over the secondconnection, thereby saving network resources.

BRIEF DESCRIPTION OF FIGURES

Now the present invention will be described by making reference topreferred embodiments, which are intended to be illustrative of theinvention, but are in no way limiting, where the description willsometime make reference to the enclosed figures, in which

FIG. 1 shows a schematic representation of a receiver and twoconnections involved in a handover process;

FIG. 2 schematically shows a receiver arranged to operate in accordancewith the present invention;

FIGS. 3 a and 3 b schematically show senders arranged to operate inaccordance with the present invention;

FIG. 4 shows a flow chart of a first example of the method of thepresent invention;

FIG. 5 shows a flow chart of a second example of the method of thepresent invention; and

FIG. 6 shows a detailed example of the signalling and data forwardingthat occurs in a handover procedure from a radio network controller toan access point of a wireless LAN, with respect to a dual-mode mobileterminal that can communicate with both the radio network controller andthe wireless LAN.

DETAILED DESCRIPTIONOF EMBODIMENTS

In the following, various embodiments of the present invention will bedescribed. Although some of the embodiments will make reference tospecific protocols (such as TCP/IP) and/or specific protocol layers(such as the link layer), the present invention is not restricted to anyspecific protocols or protocol layers. It can be applied in the contextof any data unit based communication that is subject to a handoverprocedure.

It is also noted that in the context of specific protocols andtechnologies, subdivisions of data transported over connections receivea variety of names, such as protocol data units, frames, packets,segments, cells, etc., and that in the present application all suchsubdivisions of data are generically referred to as data units.

FIG. 1 is a schematic representation of a system to which the presentinvention can be applied. Reference numeral 1 relates to a first accessnetwork, reference numeral 2 to a second access network, and referencenumeral 3 to a communication network that is arranged to forward dataunits to the access networks I and 2. Reference numeral 4 describes areceiver capable of accessing the network 3 via access network 1 andaccess network 2. More specifically, access network 1 comprises a sender10 capable of establishing a connection 51 with the receiver 4, andaccess network 2 comprises a sender 20 capable of establishing aconnection 52 with the receiver 4. For example, receiver 4 can be adual-mode mobile terminal that is capable of a first type connection(e.g. UMTS) via appropriate access network 1 and of a second technology(e.g. GPRS) via appropriate access network 2 to an underlying coretelephone network 3. Naturally, these are only examples, and the accessnetworks can relate to any suitable technology, and can e.g. becircuit-switched. The access networks can also be wireless LANs.Moreover, although it is preferable to employ the invention inconnection with handovers between access networks of differenttechnology, it is also possible that the access networks I and 2 shownin the example of FIG. 1 employ the same technology, e.g. are bothWLANs.

Moreover, it is noted that although the example of FIG. 1 only shows twoaccess networks, this is only done for the purpose of simplicity, and ingeneral the concept of the invention can be applied to handoverprocedures involving any plurality of connections between a receiver anda plurality of senders in corresponding access networks. Finally, it isalso pointed out that the invention can be applied to a system where thetwo senders between which the handover is taking place are located inone and the same access network.

The present invention is applied to a situation in which a handover of adata unit based communication from the first connection 51 to the secondconnection 52 is performed, and prior to discontinuing the communicationover the first connection 51, data units destined for receiver 4 areprovided to both the first sender and the second sender 20, i.e. amulticast (or the specific example of only having two senders, abi-cast) handover is performed.

It is noted that the invention is in no way restricted to therelationship between the establishment of the connections 51 and 52 withthe handover procedure. In other words, the invention is applicable in acase where the second connection 52 must first be established beforeperforming the handover and the first connection 51 is terminated afterthe handover, but can equally well be applied to a situation where oneor both of the connections 51, 52 are stationary. It is also noted thatalthough the present invention is preferably applied to systems usingwireless connections 51, 52, the invention can equally well be appliedto situation where one or both of connections 51, 52 are wire-bound.

The receiver 4 is appropriately arranged to connect to access networks 1and 2, i.e. more precisely to senders 10 and 20. It may be of such kindthat it can handle the two connections 51, 52 simultaneously (alsoreferred to as “make-before-break” in a situation where secondconnection 52 is established for the handover and first connection 51 isterminated after the handover), or it may be only capable of handlingone connection at a time (also referred to as “break-before-make”).

In accordance with the present invention, the handover procedure is suchthat a reference data unit among those data units provided to both thefirst sender 10 and the second sender 20 is indicated to the receiver 4.The reference data unit among the multicast units can e.g. be the firstdata unit among the multicast data units. In other words, the receiver 4is informed of the first data unit that is provided to both the firstand second sender as a part of the multicast handover, such that thereceiver is capable of identifying the subsequent data units in theoverall sequence being sent to receiver 4. Naturally, the reference dataunit does not have to be the first multicast data unit, but can also bea predefined other data unit among the multicast data units, such as thesecond, third, etc.

It is noted that the indication of the reference data unit can beprovided by the first sender 10, or by some other control entityresponsible for the handover, e.g. a control entity in network 3. Thismay also depend on which entity is handling the provision of data unitsto both the first sender 10 and second sender 20 in the multicasthandover. If the provision to both senders is performed by way of thefirst sender 10 simply forwarding data units to the second sender 20(e.g. via network 3 or by means of some other connection), then it ispreferable that the indication to receiver 4 is done by having the firstsender 10 send a control message to receiver 4 that identifies thereference data unit.

The receiver 4 is then capable of keeping a record for identifying suchdata units among the multicast data units provided to both the firstsender and the second sender that were sent over the first connectionand successfully received by receiver 4. The record can in principle bearranged for identifying any desirable amount of data units among themulticast data units that were successfully received over the firstconnection 51. It is not necessary that all successfully received dataunits are identifiable, as e.g. the identification can be restricted todata units that were not only successfully received, but also fulfilsome further desired criterion. However, it is preferable that thereceiver 4 keeps a record of all data units among the multicast dataunits that were successfully received over the first connection 51 andare subsequent in the overall sequence of the data units to thereference data unit. In other words, if the reference data unit is e.g.the first data unit of the multicast data units, then the receiver 4preferably keeps a record for identifying all the successfully receiveddata units subsequent to the first data unit.

The information on identifying those multicast data units successfullyreceived over the first connection 51 can be used in a variety of ways.This will be explained with reference to the flow chart examples shownin FIGS. 4 and 5. In FIG. 4, the method embodiment starts with step S41,in which the data units are provided to both senders, i.e. multicastingis begun. Then, in step S42, the reference data unit among the multicastdata units is indicated to receiver 4, as previously described. Step S43indicates that the receiver 4 keeps a record of the multicast data unitssuccessfully received over connection 51. Step S44 indicates the actualhandover, namely that the communication is discontinued over the firstconnection 51 and continued over second connection 52. As a consequence,sender 20 will start sending the multicast data units previouslyprovided to it.

As already mentioned in the introduction, if there would be no record inreceiver 4 that allows to identify the data units already successfullyreceived over connection 51, then the renewed sending of the same dataunits could lead to serious performance problems at higher layers.However, in accordance with the embodiment of FIG. 4, step S45 indicatesthat the receiver is capable of silently discarding those data unitsamong the multicast data units that have already been successfullyreceived over the first connection 51. As a consequence, there is nodisturbance in the performance.

FIG. 5 shows another method example, where steps S51 to S54 areidentical to previously described steps S41 to S44, respectively, suchthat a renewed description is not necessary. However, in accordance withthe method embodiment of FIG. 5, in step S55 the receiver 4 sendsinformation to the second sender 20 that allows the second sender 20 toidentify, among the multicast data units, those data units that weresuccessfully received by receiver 4 over the first connection 51. As aconsequence, the second sender 20 can then proceed by only sending thosedata units to receiver 4 that were not successfully received over thefirst connection 51. This allows the saving of network resources,especially of wireless resources if connection 52 is a wirelessconnection, as the unnecessary sending of duplicate data units iseliminated. It is understandable that this additionally avoids thepossible performance degradation at sender 4 due to receivingunnecessary duplicated data units.

The identification of the reference data units can be done in anysuitable or desirable way. For example, it is possible to add explicitdata unit identifiers to the data units, such that they can bedistinguished from one another. Such identifiers can also be providedimplicitly, e.g. in that each data unit carries an identification of upto which data item in an overall data amount it runs, such that thisinformation is different in each consecutive data unit of the overallsequence.

Furthermore, the decision regarding whether a data unit was receivedsuccessfully or not can be chosen in any suitable or desirable way.Preferably, a data unit is considered to have been successfully receivedif it is free of errors. However, it is also possible to consider a dataunit with errors as having been successfully received, if the errors arewithin specified, tolerated limits.

The determination of a successful receipt can also be subject to furtherconditions. For example, if in-order delivery is required, then a dataunit is considered to be successfully received only if it fulfils theabove-mentioned conditions with respect to errors, and is also properwith respect to the order of the sequence. In other words, even if it iserror free, but there is a data unit missing in the sequence between thejust received data unit and the last successfully received data unit,then this data unit is not considered as successfully received in theevent that in-order delivery is a requirement.

It is noted that the connections 51, 52 may be direct connections orthat there may be further entities in between, which are not shown forsimplicity. Preferably, the connections are direct connections withoutintervening elements. Furthermore, the connections 51, 52 preferablyadhere to one protocol layer, i.e. the senders 10, 20 and the receiver 4are peers of this protocol layer. For example, connections 51, 52 may belink layer connections that receive L3 data units, such as IP packets.The L3 data units are then received at layer L2, where they are alsoreferred to as L2 SDUs (Service Data Units). These SDUs are segmentedinto L2 PDUs (Protocol Data Units). The PDUs are then sent over therespective link layer connection by the respective link layer sender 10or 20. The receiver 4 then reconstructs the SDUs on the basis of thePDUs. The SDUs are identified by appropriate sequence identifiers, whichin the following will simply be referred to as 1, 2, 3, . . . for thesake of simplicity. If the receiver 4 has received SDU number 1 withouterrors (“1” e.g. representing the first SDU of the multicast SDUs),then, if in-order-delivery is required, it is waited until SDU number 2is received without error in order to judge that another SDU has beensuccessfully received. In other words, if one of the PDUs of SDU number2 was defective and receiver 4 is waiting for a retransmission, theneven if all PDUs of SDU number 3 are received without error in themeantime, SDU number 3 is not considered successfully received until SDUnumber 2 has been received without error.

In the above example of in-order-delivery, the record for identifyingsuccessfully received data units can be a simple counter that counts thedata units received without error (or within the error tolerance limits)and that were received in- order. The counter value provides fullidentification.

On the other hand, the record being kept by receiver 4 and the form inwhich receiver 4 possibly communicates information on the successfullyreceived data units to the second sender 20 can be chosen in anysuitable or desirable way, and will generally depend on the specificcircumstances.

For example the information can also be a list of data unit identifiersthat correspond to the successfully received data units. “Successful” inthis case means without or with tolerable error, as explainedpreviously. The information passed from the receiver 4 to the secondsender 20 for allowing the second sender to identify the successfullyreceived data units can then e.g. be the list itself, or the negativelist e.g. all those data units missing from the list. The second sendercan thereby refrain from sending data units that have already arrivedsuccessfully at the receiver, and can at the same time send those thathave not.

This is applicable both for situations that require in-order deliveryand such situations that do not. In the case of in-order-delivery, thereceiver can then reorder received data units into the original order.

The identifiers that can be used in such lists at the receiver and/orfor conveying information to the second sender can be chosen in anysuitable or desirable way. The identifiers can e.g. be the protocol IDfield from the header of the associated data unit, a copy of the wholeheader or some other part of the data unit, a copy of the whole dataunit, a hash function of the header or of the entire data unit, adesignated sequence number allocated to each data unit, etc.

Up to now, the invention has been described with reference to methodembodiments. However, the present invention can also be embodied in thesenders and the receiver previously mentioned. For example, FIG. 2schematically shows an embodiment of the receiver 4 described above.Receiver 4 may comprise a connector 41 for providing the firstconnection 51 to the first sender 10 and the second connection 52 to thesecond sender 20. It is noted that the term “connector” is understoodgenerically, and relates to any device capable of establishing two ormore connections to appropriate data units senders. In the example shownin FIG. 2, the connector 41 has two antennas 43 and 44, which representthe possibility of connecting to a first wireless access network and asecond wireless access network, respectively. Naturally, this is only anexample for illustration, and the connector can comprise furtherantenna, or it can be appropriate to use a single antenna for accessingdifferent wireless access networks. The connector can also haveappropriate inputs and outputs for wire-line connections. Furthermore,the data unit receiver 4 may comprise a controller 42 which is arrangedto control the overall function of receiver 4, and is especiallyarranged to control the receipt of data units over the first and secondconnection, to determine whether the data units were correctly receivedor not in accordance with the above-described principles, and forcontrolling the data unit receiver in a handover from the firstconnection 51 to the second connection 52. The controller 42 is arrangedto receive the above-mentioned indication of a reference data unit amongthe multicast data units, and is arranged to keep the record foridentifying those data units among the multicast data units that weresent over the first connection 51 and successfully received.

The controller 42 can e.g. be a programmable processor loaded withappropriate software for fulfilling the above-mentioned functions. It isnoted that the receiver 4 will generally comprise further elements, suchas a keyboard display, etc., depending on its functions, but these arenot shown as they do not relate to the present invention.

The controller 42 is preferably arranged to count the number of dataunits that were successfully received over the first connection 51, inorder to thereby establish the mentioned record of successfully receiveddata units. Furthermore, the controller 42 is preferably arranged to beable to send information to the second sender 20 that allows the secondsender 20 to identify, among the multicast data units, those data unitsthat were successfully received by the receiver 4 over the firstconnection 51. Also, the controller 42 may be arranged to use the recordthat is kept, in order to silently discard data units received over thesecond connection 52 that were already successfully received by receiver4 over the first connection 51.

FIG. 3 a shows a schematic example of a data unit sender 10 arranged inaccordance with an embodiment of the present invention, and FIG. 3 bshows a schematic example of a data unit sender 20 arranged inaccordance with an embodiment of the present invention.

The data unit sender 10 shown in FIG. 3a comprises a connector 101 forproviding the first connection 51 to receiver 4, and to the network 1for receiving the data units to be sent to receiver 4. This is shownschematically by line 103, which indicates a part of first connection51, and line 104, which establishes a connection to network 1. The dataunit sender 10 of FIG. 3a furthermore comprises a controller 102 forcontrolling the data unit sender 10 in the handover from the firstconnection 51 to the second connection 52, where the controller isarranged to forward data units received over network 1 to the secondsender 20 in the course of the handover, and to indicate to receiver 4 areference data unit among those data units provided to both the dataunit sender 10 and the other sender 20, i.e. the multicast data units.

The connector 101 is a generic element, as already explained inconnection with connection 41 of receiver 4. Furthermore, the controller102 is preferably a programmable processor running appropriate softwareto provide the above-mentioned functions. Also as explained inconnection with FIG. 2, FIG. 3 a only shows those elements important forthe present invention, and other elements that the data unit sender 10may conventionally have are not shown for simplicity. FIG. 3 b shows anexample of a data unit sender 20 for sending data units to receiver 4over the second connection 52. Similar to sender 10, sender 20 has aconnector 201 for providing a connection 52 to receiver 4 and to network2 for receiving data units. This is shown schematically by means oflines 203 and 204 respectively. Furthermore, a controller 202 isprovided for controlling the data unit sender 20 in a handover fromfirst connection 51 to second connection 52. The controller 202 isarranged to receive the above-described information from receiver 4 thatallows controller 202 to identify those data units among the multicastdata units that were successfully received by receiver 4 over the firstconnection 51.

Controller 202 is preferably arranged to only send such data units amongthe multicast data units to receiver 4 that were not successfullyreceived by receiver 4 over the first connection 51 where this controloperation is based upon the information received from receiver 4.

Now, with reference to FIG. 6, a detailed example of an application ofthe present invention to a handover from a UMTS (Universal MobileTelephone System) connection to a WLAN (Wireless Local Area Network)connection will be described. In FIG. 6, the previously describedreceiver is embodied by a dual-mode mobile terminal (MT). The sender 10related to the UMTS network is embodied by a radio network controller(RNC), which communicates with a serving GPRS service node (SGSN) and agateway GPRS service node (GGSN). The MASC (Multi-Access ServiceController) is a part of the core telephone network, and the data units(in the example of FIG. 6 IP packets) come from a server that may lieoutside of the UMTS network and the WLAN network. The WLAN network isembodied by the MPC (Media Point Controller) and the access point (AP),said AP embodying the previously described second sender 20.

Many of the information exchanges and transmissions shown in FIG. 6 areof no further relevance for the subject-matter of the present invention,and shall therefore not be explained further than what is shown in FIG.6. When a handover from UMTS to WLAN is executed, all IP packets thatare stored in the RNC and have not yet been successfully transmitted areduplicated and sent via the GGSN to the WLAN AR. This is indicated bythick arrow 61 in FIG. 6. At the same time bi- casting starts at theGGSN node, where data is forwarded to the RNC and the WLAN AR. Prior toany duplication of IP packets, the mobile terminal MT is signalled tostart an appropriate counter, called “PDU Offset Counter”, see referencenumber 62. It is noted that the term “PDU” as used in the example ofFIG. 6 relates to PDP (Packet Data Protocol) PDUs, e.g. IP packets. Thismeans that they are PDUs of the higher L3 layer and could therefore alsobe referred to as L2 SDUs.

After the second connection via the WLAN has been established, themobile terminal MT sends to the WLAN AR the value of the “PDU OffsetCounter”, see reference number 62. In the example shown at reference 63,this information is communicated via a SIP (Session Initiation Protocol)message. The WLAN AR then discards as many IP packets as indicated bythe PDU offset value (see reference 64) and transmits all further IPpackets, see reference 65. In this way, duplicate transmission ofalready received IP packets over the air interface of the WLAN, as wellas the reception of duplicate packets by a higher layer protocol likeTCP, can be eliminated.

It may also be pointed out that FIG. 6 gives an example where themulticast function is not implemented by one node, but by several nodes.Namely, the multicasting is done by both the GGSN and the RNC. Ingeneral, the multicast function can be performed or controlled by onedesignated node or by several such nodes.

Although the present invention has been described by way of preferredembodiments, these embodiments only serve to convey a clearerunderstanding, but are in no way intended to be limiting. Much rather,the invention is defined by the appended claims. Reference numerals inthe claims serve to make the claims easier to read, but have no limitingeffect.

1. A method of performing a handover of a data unit based communicationthat involves a sequence of data units, from a first connection betweena first sender and a receiver to a second connection between a secondsender R and said receiver, comprising: discontinuing said communicationover said first connection ( and continuing said communication over saidsecond connection, prior to discontinuing the communication over saidfirst connection, providing data units destined for said receiver ( toboth said first sender and said second sender, indicating to saidreceiver a reference data unit among those data units provided to bothsaid first sender and said second sender, said receiver, based on saidreference data unit, keeping a record for identifying such data unitsamong those data units provided to both said first sender and saidsecond sender that were sent over said first connection and successfullyreceived by said receiver.
 2. The method of claim 1, said receiverkeeping a record of all data units among those data units provided toboth said first sender and said second sender that were successfullyreceived over said first connection and are subsequent in said sequenceto said reference data unit.
 3. The method of claim 1, wherein saidreference data unit is the first data unit among those data unitsprovided to both said first sender and said second sender.
 4. The methodof claim 1, wherein said procedure of providing data units destined forsaid receiver (4) to both said first sender and said second senderfurther comprises said first sender forwarding said data units to saidsecond sender.
 5. The method of claim 4, wherein said procedure ofindicating to said receiver a reference data unit comprises said firstsender sending to said receiver a control message for identifving saidreference data unit.
 6. The method of claim 1, wherein said procedure ofsaid receiver keeping a record further comprises counting, with respectto said reference data unit, the number of data units successfullyreceived over said first connection.
 7. The method of claim 1, furthercomprising said receiver sending information to said second sender thatallows said second sender to identify, among those data units providedto both said first and said second sender, said data units that weresuccessfully received by said receiver over said first connection. 8.The method of claim 7, wherein said second sender, among those dataunits provided to both said first and said second sender, only sendingsuch data units to said receiver that were not successfully received bysaid receiver over said first connection.
 9. The method of claim 1wherein said receiver uses said record to silently discard data unitsbeing received over said second connection that are among those dataunits provided to both said first and said second sender and that weresuccessfully received by said receiver over said first connection. 10.The method of claim 1, said first sender belongs to a first wirelessaccess network and said second sender belongs to a second wirelessaccess network that is different from said first wireless accessnetwork.
 11. A data unit receiver, comprising: a connector for providinga first connection to a first sender and a second connection to a secondsender, and a controller for controlling the receipt of data units oversaid first and said second connection and determining whether said dataunits were correctly received or not, and for controlling said data unitreceiver in a handover of a data unit based communication that involvesa sequence of data units from said first connection to said secondconnection, said handover comprising discontinuing said communicationover said first connection and continuing said communication over saidsecond connection, said controller being arranged to receive anindication of a reference data unit among data units provided to bothsaid first sender and said second sender in the course of said handover,and being arranged to keep a record for identifying such data unitsamong those data units provided to both said first sender and saidsecond sender that were sent over said first connection and successfullyreceived by said receiver.
 12. The data unit receiver of claim 11,wherein said controller is arranged to count with respect to saidreference data unit the number of data units successfully received oversaid first connection.
 13. The data unit receiver of claim 11, whereinsaid controller is arranged to send information to said second senderthat allows said second sender to identify, among those data unitsprovided to both said first and said second sender, data units that weresuccessfully received by said receiver over said first connection. 14.The data unit receiver of claim 11, wherein said controller is arrangedto use said record to silently discard data units received over saidsecond connection that are among those data units provided to both saidfirst and said second sender and that were successfully received by saidreceiver over said first connection.
 15. A data unit sender for sendingdata units to a receiver, comprising: a connector for providing a firstconnection to said receiver and to a network for receiving said dataunits, and a controller for controlling said data unit sender in ahandover from said first connection to a second connection between asecond sender and said receiver, where said handover comprisesdiscontinuing said communication over said first connection andcontinuing said communication over said second connection, and prior todiscontinuing the communication over said first connection, providingdataunits destined for said receiver to both said data unit sender andsaid second sender, said controller being arranged to forward said dataunits received over said network to said second sender in the course ofsaid handover, and to indicate to said receiver a reference data unitamong those data units provided to both said data unit sender and saidsecond sender.
 16. A data unit sender for sending data units to areceiver, comprising: a connector for providing a connection to saidreceiver and to a network for receiving said data units, and acontroller for controlling said data unit sender in a handover from afirst connection between a first sender and said receiver to saidconnection as a second connection of said handover, where said handovercomprises discontinuing said communication over said first connectionand continuing said communication over said second connection, and priorto discontinuing the communication over said first connection, providingdata units destined for said receiver to both said first sender and saiddata unit sender, said controller being arranged to receive informationfrom said receiver that allows said controller to identify, among thosedata units provided to both said first sender and said data unit sender,data units that were successfully received by said receiver over saidfirst connection.
 17. The data unit sender of claim 16, wherein saidcontroller is arranged to only send such data units, among those dataunits provided to both said first sender and said data unit sender, tosaid receiver that were not successfully received by said receiver oversaid first connection, based on said information received from saidreceiver.